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Preface 


Conventions Used in This Book 


The following typographical conventions are used in 
this book: 


Italic 
Indicates new terms, URLs, email addresses, 
filenames, and file extensions. 

Constant width 
Used for program listings, as well as within 
paragraphs to refer to program elements such as 
variable or function names, databases, data types, 
environment variables, statements, and keywords. 

Constant width bold 
Shows commands or other text that should be typed 
literally by the user. 

Constant width italic 


Shows text that should be replaced with user- 
supplied values or by values determined by context. 


TIP 


This element signifies a tip or suggestion. 


NOTE 


This element signifies a general note. 


WARNING 


This element indicates a warning or caution. 





Using Code Examples 


Supplemental material (code examples, exercises, etc.) 
is available for download at 
https://github.com/oreillymedia/title title. 


This book is here to help you get your job done. In 
general, if example code is offered with this book, you 
may use it in your programs and documentation. You 
do not need to contact us for permission unless you’re 
reproducing a significant portion of the code. For 
example, writing a program that uses several chunks 
of code from this book does not require permission. 
Selling or distributing a CD-ROM of examples from 
O’Reilly books does require permission. Answering a 
question by citing this book and quoting example code 
does not require permission. Incorporating a 
significant amount of example code from this book into 


your product’s documentation does require 
permission. 


We appreciate, but do not require, attribution. An 
attribution usually includes the title, author, publisher, 
and ISBN. For example: “Book Title by Some Author 
(O’Reilly). Copyright 2012 Some Copyright Holder, 
978-0-596-xxxx-x.” 


If you feel your use of code examples falls outside fair 
use or the permission given above, feel free to contact 
us at permissions@oreilly.com. 


O'Reilly 


NOTE 


For almost 40 years, O’Reilly Media has provided technology 
and business training, knowledge, and insight to help 
companies succeed. 


Our unique network of experts and innovators share 
their knowledge and expertise through books, articles, 
conferences, and our online learning platform. 
O’Reilly’s online learning platform gives you on- 
demand access to live training courses, in-depth 
learning paths, interactive coding environments, and a 
vast collection of text and video from O’Reilly and 


200+ other publishers. For more information, please 
visit http://oreilly.com. 


How to Contact Us 


Please address comments and questions concerning 
this book to the publisher: 


O’Reilly Media, Inc. 

1005 Gravenstein Highway North 

Sebastopol, CA 95472 

800-998-9938 (in the United States or Canada) 
707-829-0515 (international or local) 
707-829-0104 (fax) 


We have a web page for this book, where we list 
errata, examples, and any additional information. You 
can access this page at 

http://www. oreilly.com/catalog/< catalog page>. 


To comment or ask technical questions about this book, 
send email to bookquestions@oreilly.com. 


For more information about our books, courses, 
conferences, and news, see our website at 
http://www. oreilly.com. 


Find us on Facebook: http://facebook.com/oreilly 
Follow us on Twitter: http://twitter.com/oreillymedia 


Watch us on YouTube: 
http://www. youtube.com/oreillymedia 


Acknowledgments 


Chapter 1. Overview and 
Organization 


NOTE 


With Early Release ebooks, you get books in their earliest 
form—the author’s raw and unedited content as he or she 
writes—so you can take advantage of these technologies long 
before the official release of these titles. The following will be 
Chapter 1 in the final release of the book. 


Prerequisite Knowledge 


Welcome to Web Application Security: Exploitation and 
Countermeasures for Modern Web Applications. 


This book is about hacking into web applications and 
defending your own applications from hackers or users 
with malicious intentions. 


Throughout this book we will discuss many techniques 
that hackers are using today to break into web 
applications hosted by corporations, governments and 
occasionally even hobbyists. 


The potential audience for this book is quite broad, but 
the style in which the book is written and the way that 
the examples are structured should make it ideal for 
anyone with an intermediary level background in 
software engineering. 


What does an “intermediary level background in 
software engineering” imply you might ask? 


The answer to that question will differ significantly 
from person to person. 


As far as any highly technical person is concerned, this 
book might actually only require a “beginner level 
background in software engineering”. 


However, I have chosen to define it as an 
“intermediary level background” verus a “beginner 
level background” because this book would not be 
appropriate for the general population without any 
experience writing production quality software 
applications. 


For the sake of this book, an “intermediary level 
background in software engineering” implies the 
following: 


e You can write basic CRUD (create, read, 
update, delete) programs in at least one 
programming language 


e You can write code that runs on a server 
somewhere (aka, back-end code) 


e You can write at least some code that runs ina 
browser (aka, front-end code - usually 
JavaScript) 


e You are familiar with at least one popular 
database (aka, MySql, MongoDB, etc.) 


e You know what HTTP is, and can make GET / 
POST calls over HTTP in some language or 
framework 


These skills represent the minimum criteria for 
successfully following the examples in this book. 


I have done my best to organize the topics in this book 
such that they ramp in difficulty at a maintanable pace. 


Additionally, I will try to be as verbose as possible in 
my explanations. This means whenever I cover a new 
technology I will start with a brief background and 
overview of how that technology works. 


Any experience you have beyond these bullet points is 
a plus, and will make this book that much easier for 
you to consume and derive educational value from. 


Who is this Book For? 


Prerequisite skills aside, I believe it is important to 
clarify who will benefit from this book the most. As a 
result I would like to explain who my target audience 
is. In order to do so I have structured this chapter in 
terms of learning goals and professional interests. 


If you do not fit in one of these categories, you are still 
welcome to read this book. I believe you will still learn 
many valuable or at least interesting concepts from it. 


This book is written to stand the tests of time, so if you 
decide later on you wish to persue one of the 
occupations I’ve listed when defining my target 
audience - all of the knowledge from this book should 
still be relevant. 


Software Engineers & Web Application 
Developers 


I believe it would be fair to say that the primary 
audience for this book is an early to mid career 
software engineer or web application developer. 
Ideally this reader is interested in gaining deep 
understanding of either offensive techniques used by 
hackers, or defensive techniques used by security 
engineers to defend against hackers. 


Often the titles “web application developer” and 
“software engineer” are interchangable which might 
lead to a bit of confusion considering I will use both of 
them throughout the upcoming chapters. Let’s start 
this book off with some clarification. 


SOFTWARE ENGINEERS 


In my mind, and for the sake of specification - when I 
use the term “software engineer” I am refering to a 
generalist who is capable of writing software that runs 
on a variety of platforms. Software engineers will 
benefit from this book in several ways. 


First off, much of the knowledge contained in this book 
is transferable with minimal effort to software that 
does not run on the web. It is also transferable to other 
types of networked applications, with native mobile 
applications being the first that come to mind. 


Furthermore, several exploits discussed in this book 
take advantage of serverside integrations involving 
communication with a web application and another 
software component. As a result, it is safe to consider 
any software that interfaces with a web application as 
a potential threat vector (databases, CRM, accounting, 
logging tools, etc). 


WEB APPLICATION DEVELOPERS (FULL-STACK, 
BACK-END, FRONT-END) 


On the other hand, a “web application developer” by 
my definition is someone who is highly specialized in 
writing software that runs on the web. These are often 
further subdivided into front-end, back-end and full- 
stack developers. 


Historically many attacks against web applications 
have targeted server-side vulnerabilities. As a result I 
believe this book’s use case for a back-end or full-stack 
developer is very transparent and easily understood. 


I also believe this book should be valuable for other 
types of web application developers, including those 
who do not write code that runs on a server but 
instead on a web browser (front-end / JavaScript 
developers). 


As I will explain in the upcoming chapters, many of the 
ways by which hackers take advantage of today’s web 
applications originate via malicious code running in 
the browser. Some hackers are even taking advantage 
of the browser DOM or CSS stylesheets in order to 
attack an application’s users. 


These points suggest that it is also important for front- 
end developers who do not write server-side code to 
be aware of the security risks their code may expose 
and how to mitigate those risks. 


GENERAL LEARNING GOALS 


This book should be a fantastic resource for any of the 
above looking to make a career change to a more 
security-oriented role. Or to learn how to beef up the 
defenses in their own code or the code maintained by 
their organization. 


If you want to defend your application against very 
specific exploits this book is also for you. This book 
follows a unique structure, which should enable it to 
be used as a security reference without ever having to 
read any of the chapters that involve hacking. That is 
of course, if that is your only goal in purchasing this 
book. 


I would suggest reading from cover to cover for the 
best learning experience, but if you are looking only 
for reference on securing against specifics types of 
hacks - just flip the book halfway open and get started 
reading. 


Security Engineers, Pen Testers & Bug 
Bounty Hunters 


As a result of the way this book is structured - this 
book can also be used as a resource for penetration 
testing, bug bounty hunting, and any other type of 
offense-oriented security work. If this type of work is 


relevant or interesting to you than you may find the 
first half of the book more to your liking. 


This book will take a deep-dive into how exploits work 
from both a code level and an architectural level 
rather than simply executing well known open source 
(OSS) scripts or making use of paid security 
automation software. 


Because of this there is a second audience for this 
book - software security engineers, IT security 
engineers, network security engineers, penetration 
testers and bug bounty hunters. 


This book will be very beneficial to existing security 
professionals who understand conceptually how many 
attacks work but would like a deep-dive into the 
systems and code behind a tool or script. 


In today’s security world, it is a common-place for 
penetration testers to operate using a wide-array of 
pre-built exploit scripts. This has lead to the creation of 
many paid and open source tools that automate classic 
attacks and attacks that can be easily run without deep 
knowledge regarding the architecture of an 
application or the logic within a particular block of 
code. 


The exploits and countermeasures contained within 
this book will be presented without the use of any 
specialized tools. Instead we will rely on our own 
scripts, network requests, and the tooling that comes 
standard in unix-based operating systems as well as 
the standard tooling present in the three major web 
browsers (Chrome, FireFox, Edge). 


This is not to take away from the value of specialized 
security tools - in fact I think that many of them are 
exceptional and make delivering professional, high 
quality penetration tests much easier! 


Instead, the reason this book will not contain the use of 
specialized security tools is so that we can focus on the 
most important parts of finding a vulnerability, 
developing an exploit, prioritizing data to compromise 
and making sure you can defend against all of the 
above. 


As a result of this, I believe by the end of this book you 
will be prepared to go out into the wild and find new 
types of vulnerabilities, develop exploits against 
systems that have never been exploited before and 
harden the most complex systems against the most 
persistent attackers. 


Conclusion 


While it’s unlikely this book will help you get a date or 
become an elite athlete - it might just be for you if you 
meet one of the following critieria: 


e You are a software engineer or web application 
developer 


= You wish to transition to role in security 
engineering 


= You want to write more secure code 


» You want to understand how to harden a 
specific part of your codebase 


e You are a security professional 


= You want to learn how exploits work ata 
code level 


=» You want to learn how to exploit software 
without relying on tools 


» You wish to better understand specific 
efforts that are taken by engineering 
teams to prevent exploitation 


e You are any of the above AND 
» You want a career in penetration testing 


» You want to start making some money on 
bug bounties (aka responsible disclosure 
programs) 


How is this Book Organized? 


You will soon find that this book is structured quite 
differently than most other technology books out 
there. This is intentional. 


This book is purposefully structured in a way such that 
there is a 1:1 ratio of chapters regarding hacking 
(offense) and security (defense). 


After beginning our adventure with a bit of a history 
lesson and some exploration into the technology, tools 
and exploits of the past - we will move onto our main 
topic: exploitation and countermeasures for modern 
web applications. Hence the subtitle of this book. 


The main content in this book is structured into three 
major “parts”, each part containing many individual 
chapters covering a wide array of topics. 


Ideally, you would venture through this book in a linear 
fashion - from page one all the way to the final page. 
Reading this book in that order would provide the 
greatest learning possible. 


As mentioned prior, this book can also be used as 
either a hacking reference or a security engineering 
reference by focusing in on the first or second half 
respectively. 


By now you should understand how to navigate the 
book, so lets go over the three main parts of this book 
SO we can grasp the importance of each. 


Recon 


The first part of this book is “Recon”, where we will 
explore ways to gain information regarding a web 
application without necessarily trying to hack it. 


In Recon, we will explore a number of important 
technologies and concepts that are essential to master 
if you wish to become a hacker. These topics will also 
be important to anyone looking to lock down an 
existing application, because the information exposed 
by many of these techniques can be mitigated with 
appropriate planning. 


I have had the opportunity to work with what I believe 
to be some of the best penetration testers and bug 
bounty hunters in the world. Through my 
conversations with them and my analysis of how they 
do their work - I’ve come to realize this topic is much 
more important than many other books make it out to 
be. 


In fact, I would go as far as to say that for many of the 
top bug bounty hunters in the world - expert level 
reconnaissance ability is what differentiates these 


“great” hackers from simply “good” hackers. In other 
words it’s one thing to have a big gun (in this case, 
knowing how to build exploits), but that alone isn’t 
very valuable if you cannot figure out how and where 
to land a shot for the most damage. In our case 
(hacking web applications), the first role of 
reconnaissance is to look for potential weaknesses in 
an application that we can attempt to exploit. 


If fantasy-based analagies hit closer to home, you could 
think of recon skills as something akin to a rogue in an 
RPG. In our case, the rogue’s job isn’t to do lots of 
damage - but instead to scout ahead of the group and 
circle back with intel. It’s the guy who helps line up the 
shots, and figures out which which battles will have the 
greatest rewards. 


The last part in particular is exceedingly valuable, 
because against well defended targets it’s likely many 
types of attacks could be logged. This means you might 
only get one chance to exploit a certain software hole 
before it is found and closed. 


As a result these key points, we can safely conclude 
that the second use of reconnaissance is figuring out 
how to priotize your exploits. 


If you are interested in a career as a penetration tester 
or a bug bounty hunter, this part of the book will be of 


utmost importance to you. This is largely because in 
the world of bug bounty hunting, and to a lesser extent 
penetration testing - tests are performed “black box” 
style. “Black box” testing is a style of testing where the 
tester has no knowledge of the structure and code 
within an app, and hence must build their own 
understanding of the application through careful 
analysis and investigation. 


Offense 


The second part of this book is “Offense”. Here the 
focus of the book moves from recon and data 
gathering to analysing code and network requests. 
Than with this knowledge we will attempt to take 
advantage of insecurely written or improperly 
configured web applications. 


In this part of the book we will learn how to both build 
and deploy exploits. These exploits will be designed to 
steal data or change the behavior of an application 
forcibly. 


This part of the book will build on top of the knowledge 
from the first part “Recon”. Using our previously 
acquired reconnisance skills in conjunction with newly 
acquired hacking skills we will begin taking over and 
attacking demo web applications. 


The way this part will be organized, is on an exploit by 
exploit basis. That means, each chapter underneath 
“offense” will explain in detail a different type of 
exploit. 


These chapters should start with an explanation of the 
exploit itself so you can understand how it works 
mechanically. Than we will discuss how to search for 
vulnerabilities where this exploit can be applied. 
Finally, we will craft a payload specific to the demo 
application we are exploiting. We will than deploy the 
payload, and obvserve the results. 


A good example of this is Cross Site Scripting (XSS), 
which will be one of the first exploits we dig into. XSS 
is a type of attack which works against a wide array of 
web applications, but can be applied to other 
applications as well (example: mobile apps, flash / 
actionscript games, etc). This particular attack involves 
writing some malicious code on your own machine, but 
than taking advantage of poor filtration mechanisms in 
an app which will than allow your script to execute on 
another user’s machine. 


When we discuss an exploit like an XSS attack, we will 
start with a vulnerable app. This demo app will be 
strait and to the point, ideally just a few paragraphs of 
code. From this foundation, we will write a block of 
code to be injected as a payload into the demo app 


which will than take advantage of a hypothetical user 
on the other side. 


Sounds simple doesn’t it? And it should be. Without 
any defenses, most software systems are easy to break 
into. As a result, with an exploit like XSS where there 
are many defenses - we will progressively dig deeper 
and deeper into the specifics of writing and deploying 
an attack. 


We will initially attempt to break down routine 
defenses, and eventually move on to bypassing more 
advanced defense mechanisms. Remember, just 
because someone built a wall to defend their codebase 
doesn’t mean you can’t go over it or underneath it. 
This is where we will get to use some creativity and 
find some unique and interesting solutions. 


This part of the book is important across the board as 
understanding the mindset of a hacker is often vital for 
architecting secure codebases. That being said, those 
interested in hacking, penetration testing or bug 
bounty hunting will probably find this part of the book 
to be the most interesting. 


Defense 


The third and final part of this book “Defense” is about 
securing your own code against hackers. 


In this part of the book, we will go back and look at 
every type of exploit we covered in part two and 
attempt to consider them again with a completely 
opposite viewpoint. 


This time, we will not be concentrating on breaking 
into software systems but instead attempting to 
prevent or mitigate the probability that a hacker could 
break into our systems. 


In this part you will learn how to protect against 
specific exploits from part two, in addition to learning 
general protections that will secure your codebase 
against a wide variety of attacks. These general 
protections range from “secure by default” 
engineering methologies to secure coding best 
practices which can be enforced easily in an 
engineering team using tests and other simple 
automated tooling (such as a linter). 


Beyond learning how to write more secure code, you 
will also learn a number of increasingly valuable tricks 
for catching hackers in the act - and improving your 
organization’s attitude towards software security. 


You can expect the average chapter in this part of the 
book to be structured somewhat akin to the hacking 
chapters in part two. We will begin with an overview of 


the technology and skills required as we begin 
preparing a defense against a specific type of attack. 


Initially we will prepare a basic level defense, which 
should help mitigate attacks but may not always fend 
off the most persistant hackers. 


Finally, we will improve our defenses to the point 
where most if not all hacking attempts will be stopped. 


At this point, the structure of part three may begin to 
differ from that of part two - as we discuss tradeoffs 
that come as a the result of improving application 
security. 


Generally speaking, all measures of improving security 
will have some type of trade off outside of security. It 
may not be your place to make suggestions on what 
level of risk should be accepted at the cost of your 
product - but you should be aware of the tradeoffs 
being made. 


Often times, these tradeoffs come in the form of 
application performance. The more efforts you take to 
read and sanitize data, the more operations are 
performed outside of the standard functionality of your 
application. Hence a secure feature typically requires 
more computing resources than an insecure feature. 


With further operations also comes more code, which 
means more maintence, tests and engineering time. 
This implies that there is often a development 
overhead to security. 


Finally, some security precations will come at the cost 
of reduced usability. 


A very simple example of this is a login form. If an 
error message for an invalid username is displayed to 
the user when attemping to log in, it becomes 
significantly easier for a hacker to brute force 
username / password combinations. 


This occurs because the hacker no longer has to find a 
list of active login usernames, because the application 
will confirm a user account for him. He simply needs to 
successfully brute force a few usernames, which can 
be confirmed and logged for later break-in attempts. 


Next the hacker only needs to brute force passwords 
versus brute forcing username-password 
combinations, which implies significantly decreased 
mathematical complexity - hence taking much less time 
and resources. 


Furthermore, if the application uses an email and 
password scheme for log in rather than a username 
and password scheme than we have another problem. 


A hacker can use this log in form to find valid email 
addresses which can be sold for marketing or spam 
purposes. Even if precations are taken to prevent 
brute forcing, carefully crafted inputs for example 
first.last@company.com, firstlast@ company.com, 
firstl@ company.com can allow the hacker to reverse 
engineer the schema used for company email accounts 
and pinpoint the valid accounts of execs for sales or 
particular individuals with important access criteria 
for phishing. 


As a result of this, it is often considered a security best 
practice to provide more generic error messages to 
the user. 


Of course this change conflicts with the user 
experience, as more specific error messages are 
definitely ideal for the usability of your application. 


This a great example of a tradeoff that can be made for 
improved application security, but at the cost of 
reduced usability. This should give you an idea of the 
type of tradeoffs that will be discussed in part three of 
this book. 


This part of the book is going to be extremely 
important for any security engineer who wants to beef 
up their skills, or software engineer looking at 
transitioning to a security engineering role. It will also 


be valuable to anyone who just wants to write more 
secure code, regardless of their role. 


Similarly to part two - understanding how an 
application’s security can be improved is a valuable 
asset for any type of hacker. This is because while 
routine defenses can often be easily bypassed, more 
complex defenses require deeper understanding and 
knowledge to bypass. 


This is further evidence as to why I suggest reading 
the book from start to finish. 


Although the various parts of this book may give you 
more valuable learning depending on your goals - | 
doubt any of it will be wasted. Cross training of this 
sort is particularly valuable, as each part of the book is 
just another perspective on the same puzzle. 


Language and Terminology 


It has probably become evident so far that this book 
aims to teach you a number of very useful, but also 
very rare and particular skills. 


While these skills are increasingly valuable, and will 
very much improve your saleability on the job market - 
they are also quite difficult to learn, requiring focus, 
aptitude and the capacity to pick up a whole new 


mental model that defines how you look at web 
applications. 


In order to correctly communicate these new skills, we 
will need to establish some common language. This is 
important to help me guide you through the book 
without confusion, but also important to help you 
express your new ideas in a way that is consistent 
across security and engineering organizations. 


As a new term or phrase is introduced in this book 
from here on out, I will do my best to explain it. In 
particular when dealing with acryonyms, I will spell 
out the acryonym first prior to using the acryonym by 
itself. You have seen this before when I spelled out 
Cross Site Scripting (XSS). 


Beyond that, I have done my best to determine what 
terms and phrases might need explaining. I have 
collected them and organized them in the following 
tables. 


If you ever stumble across language you don’t fully 
understand, feel free to jump back to this chapter 
(bookmark it!) and see if it is listed here. 


If it is not, feel free to send an email to my editor and 
perhaps we can include it in the next edition of the 


book - should I be lucky enough to sell enough copies 
to warrant a sequel! 


Occupation 
Description 
Hacker 


Someone who breaks into systems, typically in order to exfiltrate 
data or cause the system to perform in a way it’s developers did 
not originally intend. 


Penetration Tester 


Someone who is paid to break into systems, often in the same 
ways a hacker would. Unlike the hacker, penetration testers are 
paid to report bugs and oversights in the application software so 
that the company that owns the software can fix it before it is 
broken into by a hacker with malicious intent. 


Bug Bounty Hunter 


A freelance penetration tester, often large companies will create 
“responsible disclosure programs” that award cash prizes for 
reporting security holes. Some bug bounty hunters work full 
time, but often times these are full-time proffesionals who 
participate after work for extra money. 


Software Security Engineer (also called: Product Security 
Engineer) 


A software engineer who’s role is to improve the security of an 
organization’s codebase and application architecture. 


Term 
Description 
Vulnerability 


A bug in a software system, often as a result of engineering 
oversight or unexpected functionality when connecting multiple 
modules together. This particular type of bug allows a hacker to 
perform un-intended actions against the software system. 


Attack Surface 


A list of vulnerabilities in an application that a hacker will build 
when determining how best to attack a software system. 


Exploit 


Typically a block of code, or list of commands that can be used to 
take advantage of a vulnerability. 


Payload 


An exploit that has been formatted in a way that allows it to be 
sent to a server to take advantage of a vulnerability. Often this 
just means packaging up an exploit into the proper format to be 
sent over a network. 


Red Team 


A team often comprised of penetration testers, network security 
engineers and software security engineers. This team attempts to 
hack into a companies software to assess the companie’s ability 
to stand up against actual hackers. 


Blue Team 

A team often comprised of software security engineers, and 
network security engineers. This team attempts to improve a 
companie’s software security, often using feedback from a red 


team to drive priortization. 


Web Site 


A series of information documents accessable via the internet 
typically over the HTTP protocol. 


Web Application 


A desktop-like application that is delivered via the internet and 
run inside of a browser rather than a host operating system. 
These differ from traditional websites in that they have many 
levels of permissions, store user input in databases and often 
allow users to share content between eachother. 


Acryonym 
Description 
XSS 


Cross Site Scripting - a type of attack that involves forcing 
another client (often a browser) to run code written by a hacker. 


CSRF 


Cross Site Request Forgery - an attack where a hacker is able to 
take advantage of a privileged user’s permissions in order to 
make requests against a server. 


XXE 


XML External Entity - an attack that relies on an improperly 
configured XML parser to steal local files on the webserver or 
include malicious files from another webserver. 


OSS 


Open Source Software - software that is freely availible for both 
consumption and for modification. Often published under 
licenses like MIT, Apache, GNU or BSD. 


SoDL 
Secure Software Development Lifecycle - a common framework 


that allows software engineers and security engineers to work 
together in order to write more secure code. 





Chapter 2. The History 
of Software Security 


NOTE 


With Early Release ebooks, you get books in their earliest 
form—the author’s raw and unedited content as he or she 
writes—so you can take advantage of these technologies long 
before the official release of these titles. The following will be 
Chapter 2 in the final release of the book. 


The Origins of Hacking 


In the past two decades hackers have gained more 
publicity and notoriety than ever before. 


As a result of this it’s easy for anyone without the 
appropriate background to assume that hacking is a 
concept closely tied to the internet and that most 
hackers emerged in the last twenty years. 


But that’s only a partial truth. While the number of 
hackers worldwide has definitely exploded with the 
rise of the world wide web, hackers have been around 
since the middle of the 20th century - potentially even 
earlier depending on what you define as “hacking”. 


Many experts debate the decade which marks the true 
origin of modern hackers because a few significant 
events in the early 1900’s showed significant 
resemblance to the hacking you see in today’s world. 


For example, there have been specific isolated 
incidents that would likely qualify as hacking prior in 
the 1910’s and 1920’s, most of whom involved 
tampering with Morse code senders and recievers or 
interfering with the transmission of radio waves. 


However, while these events did occur - they where 
not incredibly common and it is difficult to pinpoint 
large scale operations that where abrupted as a result 
of these technologies being abused. 


It is also important to note that Iam no historian. I am 
a security professional with a background in finding 
solutions to deep architectural and code level security 
issues in enterprise software. 


Prior to this I spent many years as a software engineer 
writing web applications in various languages and 
frameworks. I continue writing software today in the 
form of security automation, in addition to contributing 
to various projects on my own time as a hobby. 


This means that I am not here to argue specifics or 
debate alternative origin stories. Instead this section is 


compiled based off of many years of independent 
research, with the emphasis being on the lesssons we 
can extract from these events and apply today. 


Because this chapter is not intended to be a 
comprehensive overview but instead a reference for 
critical historical events - we will begining our timeline 
in the early 1930’s. 


Now without further interuption, let us examine a 
number of historical events that helped shape the 
relationship between hackers and engineers today. 


The Enigma Machine, Circa 1930 


The term “Enigma Machine” refers to a machine that 
used electricity-powered mechanical rotors to both 
encrypt and decrypt text-based messages sent over 
radio waves. The device had German origins and 
would become an important technological 
development during the second world war. 


The device itself looked akin to a large square or 
rectangular mechanical typewriter. On each keypress, 
the rotors would move and record a seemingly-random 
character which would than be transmitted to all 
nearby Enigma Machines. 


These seemingly-random characters where however 
not random, and instead defined by the rotation of the 
rotor and a number of configuration options that could 
be modified at any time on the device. 


Any enigma machine with an specific configuration 
could read, or “decrypt” messages sent from another 
machine with an identical configuration. This made the 
enigma machine extremely valuable for sending 
crucial messages while avoiding interception. 


While a sole inventor of the rotary encryption 
mechanism used by the the machine is hard to 
pinpoint, the technology was popularized by a two-man 
company called Chiffriermaschinen AG based out of 
Germany. Chiffriermaschinen AG traveled throughout 
Germany demonstrating the technology between 1920 
and 1930 which led to the German military adopting 
the technology in 1928 in order to secure top-secret 
military messages in transit. 


The ability to avoid the interception of long-distance 
messages was a radical development that had never 
before been possible. In the software world of today 
the interception of messages is still a popular 
technique that hackers try to employ, often called a 
“man in the middle” attack. Today’s software uses 
similar (but much more powerful) techniques to those 


that the enigma machine used 100 years ago in order 
to protect against such attacks. 


While the enigma machine was incredibly impressive 
technology for it’s time, it was not without any flaws. 
Because the only criteria for interception and 
decryption was an enigma machine with an identical 
configuration to the sender - a single comprimised 
configuration log (or “private key”, in today’s terms) 
could render an entire network of enigma machines 
useless. 


In order to combat this, any groups sending messages 
via enigma machine would change their configuration 
settings on a regular basis. 


Reconfiguring enigma machines was a time-consuming 
process. First the configuration logs must be exhanged 
in person, as secure ways of sharing these remotely 
did not yet exist. Sharing configuration logs between a 
network of two machines and two operators might not 
be painful. But a larger network, say 20 machines 
could require multiple messengers to deliver the 
configuration logs - each increasing the probability of a 
configuration log being intercepted and stolen, or 
potentially even leaked or sold. 


The second problem with sharing configuration logs 
was that manual adjustments to the machine itself that 


where required for the enigma machine to be able to 
read, encrypt and decrypt a new messages sent from 
other enigma machines. This meant that a specialized 
and trained staff member must be present incase a 
configuration update was needed. 


This all occured in an era prior to software, so these 
configuration adjustments required tampering with 
the hardware and adjusting the physical layout and 
wiring of the plugboard. This meant that the adjuster 
needed a background in electronics, which was very 
rare in the early 1900’s. 


As a result of how difficult and time-consuming it was 
to update these machines, updates would typically 
occur on a monthly basis - daily for mission critical 
communication lines. This means that if a key was 
intercepted or leaked, all transmissions for the 
remainder of the month could be intercepted by a 
malicious actor - the equivilent of a hacker today. 


The type of encryption these enigma machines used is 
now known as a symmetric key algorithm, which is a 
special type of cipher that allows for the encryption 
and decryption of a message using a single 
cryptographic key. 


This family of encryption is still used today in software 
in order to secure data in transit (between sender and 


reciever), but with many improvements on the classic 
model that gained popularity with the enigma 
machine. 


In software, keys can be made much more complex. 
Modern key generation algorithms produce keys so 
complex that attempting every possible combination 
(aka, “Brute Forcing”) with the fastest possible 
modern hardware could easily take more than a 
million years. 


Additionally, unlike the enigma machines of the past - 
software keys can change rapidly. 


Depending on the use case, keys can be regenerated 
on every user session (per-login), on every network 
request, or on a scheduled interval. When this type of 
encryption is used in software, a leaked key might 
expose you for a single network request in the case of 
per-request regeneration or worst-case-scenario a few 
hours in the case of per-login (per-session) 
regeneration. 


If you trace the lineage of modern cryptography back 
far you will eventually reach World War II in the 
1930’s. It’s safe to say that the enigma machine was a 
major milestone in securing remote communications. 


From this, we can conclude that the enigma machine 
was an essential development in what would later 
become the field of software security. 


But the Enigma machine was also an important 
technological development in regards to those who 
would be eventually known as “hackers”. 


The adoption of enigma machines by the axis powers 
during World War II, resulted in an extreme pressure 
for the allies to develop encryption-breaking 
techniques. Dwight D Eisenhower himself claimed that 
doing so would be essential for victory against the 
Nazis. 


In September of 1932, a Polish mathematician named 
Marian Rejewski was provided a stolen Enigma 
Machine. At the same time a French spy named Hans- 
Thilo Schmidt was able to provide him with valid 
configurations for September and October of 1932. 


This allowed Marian to intercept messages from which 
he could begin to analyze the mystery of enigma 
machine encryption. 


Marian was attempting to determine how the machine 
worked both mechanically and mathematically. He 
wanted to understand how a specific configuration of 


the machine’s hardware could result in an entirely 
different encrypted message being output. 


Marian attempted decryption based on a number of 
theories as to what machine configuration would lead 
to a particular output. By analyzing patterns in the 
encrypted messages, and coming up with theories 
based on the mechanics of the machine - Marian and 
two co-workers Jerzy Rozycki and Henryk Zygalski 
eventually reverse engineered the system. 


With the deep understanding of enigma rotor 
mechanics and board configuration that the team 
developed they where able to make educated guesses 
at which configurations would result in what 
encryption patterns. 


In doing so, they could reconfigure a board with 
reasonable accuracy and after several attempts begin 
reading encrypted radio traffic. 


By 1933 the team was intercepting and decrypting 
enigma machine traffic on a daily basis. 


Much like the hackers of today, Marian and his team 
intercepted and reverse engineered encryption 
schemes in order to get access to valuable data 
generated by a source other than themselves. For 
these reasons, I would consider Marian Rejewski and 


the team assisting him as some of the world’s earliest 
hackers. 


In the following years Germany would continually 
increase the complexity in their Enigma Machine 
encryption. This was done by gradually increasing the 
number of rotors required to encrypt a character. 


Eventually the complexity of reverse engineering a 
configuration would become too difficult for Marian’s 
team to break in a reasonable timeframe. 


This development was also important, because it 
provided a look into the ever-evolving relationship 
between hackers and those who try to prevent 
hacking. 


This relationship continues today, as creative hackers 
continually iterate and improve their techniques for 
breaking into software systems. And on the other side 
of the coin, smart engineers are continually developing 
new techniques for defending against the most 
innovative hackers. 


Automated Enigma Code Cracking, 
Circa 1940 


Alan Turing was an English mathematician is best 
known for his development a test known today as “The 


Turing Test”. 


The Turing Test was a test developed in order to rate 
conversations generated by machines based on the 
difficulty to differenciate those conversations from the 
conversations of real human beings. 


Thist test is often considered to be one of the most 
foundational philosophies in the field of artificial 
intelligence (AI). 


While Alan Turing is best known for his work in 
artificial intelligence, he also was a pioneer in 
cryptography and automation. 


In fact, prior to and during World War II Alan’s 
research focus was primarily on cryptography rather 
than Al. 


Starting in September 1938, Alan worked part time at 
the Goverment Code and Cypher School (GC&CS). 
GC&CS was a research and intelligence agency funded 
by the English army which was located in Bletchley 
Park, England. 


Alan’s research primarily focused on analysis of 
enigma machines. At Bletchley Park Alan would 
research enigma machine cryptography alongside his 


than-mentor Dilly Knox who at the time was an 
experienced cryptographer. 


Much like the Polish mathematicians before them, Alan 
and Dilly wanted to find a way to break the (now 
significantly more powerful) encryption residing in 
German enigma machines. 


Due to their partnership with the Polish Cipher Bureau 
the two gained access to all of the research Marian’s 
team had produced nearly a decade earlier. 


This meant they already had a deep understanding of 
the machine mechanically. They understood the 
relationship between the rotors and wiring, and knew 
about the relationship between the device 
configuration and the encryption that would be ouput. 


Marian’s team had been able to find patterns in the 
encryption that would allow them to make educated 
guesses regarding a machines configuration. But this 
was not scalable now that the number of rotors in the 
machine had been increased as much as ten-fold. 


In the amount of time required to try all of the 
potential combinations based on an such a system, a 
new configuration would have already been issued. 


Because of this, Alan and Dilly where looking for a 
different type of solution. They wanted a solution that 
would scale, and could be used to break new types of 
encryption. They wanted a general purpose solution, 
rather than a highly specialized solution. 


Introducing the “Bombe”. 


A bombe was an electricity powered mechanical device 
that would attempt to automatically reverse engineer 
the position of mechanical rotors in an enigma 
machine based on mechanical analysis of messages 
sent from such machines. 


The first bombes where actually built by the Polish, in 
an attempt to automate Marian’s work. Unfortunately, 
these devices where designed to find the configuration 
of enigma machines with very specific hardware. In 
particular, they where inneffective against machines 
with more than three rotors. 


Because the Polish bombe could not scale against the 
development of more complex enigma machines, the 

Polish cryptographers eventually went back to using 

manual methods for attempting to decipher German 

wartime messages. 


Alan Turing believed that the reason the original 
machines failed, was because they where not written 


in a general purpose manner. 


In order to develop a machine which could decipher 
any enigma configuration (regardless of the number of 
rotors), he began with a simple assumption: in order to 
properly design an algorithm to decrypt an encrypted 
message you must first know a word or phrase that 
exists within that message and it’s position. 


Fortunately for Alan, the German military had very 
strict communication standards. Each day a message 
was sent over an encrypted enigma radio waves 
containing a detailed regional weather report. 


This is how the German military would ensure all units 
had sufficient knowledge of weather conditions 
without sharing them publically to anyone listening on 
the radio. The German’s did not know that Alan’s team 
would be able to reverse engineer the purpose and 
position of these reports. 


As a result of knowing the inputs (weather data) being 
sent through a properly configured enigma machine, 
algorithmically determining the outputs would become 
much easier. 


Alan would use this newfound knowledge to determine 
an bombe configuration that could work independently 


of the number of rotors the enigma machine it was 
attempting to crack relied on. 


Alan requested a budget to build a bombe that would 
accurately detect the configuration requirements 
needed to intercept and read encrypted messages 
from German enigma machines. 


Once the budget was approved, Alan constructed a 
bombe comprised of 108 drums that could rotate as 
fast as 120 RPM. This machine would run through 
nearly 20,000 possible enigma machine configurations 
in just 20 minutes. 


This meant any new configuration could be rapidly 
comprimised. Enigma encryption was no longer a 
secure means of communication. 


Today we know Alan’s reverse engineering strategy as 
a “Known-plaintext Attack” or KPA. It’s a brute-force 
algorithm that is made much more efficient by 
providing prior input/output data to the algorithm. 


Similar techniques are used by modern hackers in 
order to break encryption on data stored or used in 
software. 


The machine Alan built would mark an important point 
in history as it was one of the first automated hacking 


tools ever built. 


Telephone “Phreaking’”, Circa 1950 


After the rise of the Enigma Machine in the 1930’s and 
the cryptographic battle that occured between major 
world powers - the introduction of the telephone would 
become the next major event in our timeline. 


The telephone allowed normal everyday people to 
communicate with each other over large distances, 
and at rapid speed. As telephone networks grew, they 
would require automation in order to function at scale. 


In the late 1950’s telecoms like ATT began 
implementing new phones that could be automatically 
routed to a destination number based on audio signals 
emitted from the phone unit itself. Pressing a key on 
the phone pad would emit a specific audio frequency 
which would be tramitted over the line and 
interpretted by a machine in a switching center. A 
switching machine would translate these sounds into 
numbers and route the call forwards to the 
appropriate reciever. 


This system was known as “tone dialing”, and would be 
an essential development that telephone networks at 
scale could not function without. Tone dialing 
dramatically reduced the overhead of running a 


telephone network, since the network no longer 
needed an operator to manually connect every call. 
Instead, one operator overseeing a network for issues 
could now manage hundreds of calls in the same time 
that one call would have taken previously. 


Within a short period of time, small groups of people 
began to realize that any systems built on top of the 
interpretation audio tones could be easily manipulated. 
Simply learning how to reproduce identical audio 
frequencies near to the telephone reciever could 
interfere with the intended functionality of the device. 


Hobbiests who experiemented with manipulating this 
technology would eventually go on to be known 
“phreakers” - an early type of hacker specializing in 
breaking or manipulating telephone networks. 


Although the true origin of the term is not known, the 
term “phreaking” has several generally accepted 
possible origins. The term is most often thought to be 
derived from two words, “freaking” and “phone”. 


There is an alternatively suggested derivation that I 
believe makes more sense. I believe that the term 
phreaking originated from “audio frequency” in 
response to the audio signalling languages phones of 
the time used. 


I believe this explaination is makes more sense since 
we Can see that the origin of the term is very close 
chronologically to the release of ATT’s original tone 
dialing system. Prior to tone dialing, telephone calls 
would have been much more difficult to tamper with 
because each call required an operator to connect the 
two lines. 


We can trace phreaking back to several events, but the 
most notorious case of early phreaking was the 
discovery and utilization of the 2600hz tone. A 2600hz 
audio frequency was used internally by ATT to signal a 
call had ended. It was essentially an “admin command” 
that was built into the original tone dialing systems. 


Emitting a 2600hz tone would stop a telecom’s 
switching system from realizing a call was still open 
(log the call as ended, although it was still ongoing). 
This allowed expensive international calls to be placed 
without a bill being recorded or sent to the caller. 


The origin of the discovery of the 2600hz tone is often 
attributed to two events. First off, a young boy named 
Joe Engressia was known to have a whistling pitch of 
2600hz and would reportedly show off to his friends by 
whistling a tone that could prevent phones from 
dialing. Some consider Joe to be one of the original 
phone phreakers, although his discovery came by 
accident. 


Later on a friend of Joe Engressia’s named John 
Draper discovered that toy whistles included in Cap’n 
Crunch cereal boxes mimicked a 2600hz tone. Because 
these whistles could generate a single frequency 
2600hz tone, careful usage of the whistle could also 
generate free long distance phone calls through the 
same technique. 


Knowledge of these techniques spread throughout the 
western world, eventually leading to the generation of 
hardware that could match specific audio frequencies 
with the press of a button. 


The first of these hardware devices was known as a 
“blue box”. Blue boxes would play a nearly-perfect 
2600hz signal in order to allow anyone who owned one 
to take advantage of the free calling bug inherit in 
telecom switching systems. 


Blue boxes where only the beginning of automated 
phreaking hardware, as later generation phreakers 
would go on to tamper with pay phones, prevent billing 
cycles from starting without utilizing a 2600hz signal, 
emulate military communication signals, and even fake 
caller ID. 


From this we can see that architects of early telephone 
networks only considered normal people and their 
communication goals. In the software world of today is 


known as the “best-case scenario” design case. 
Designing based off of this was a fatal flaw, but it would 
become an important lesson that is still relevant today. 
That lesson is to always consider the “worst-case 
scenario” first when designing complex systems. 


Eventually, knowledge of weaknesses inherit in tone 
dialing systems became more widely known - which 
would lead to budgets being allocated in order to 
develop countermeasures to protect telecom profits 
and call integrity against phreakers. 


Anti-Phreaking Technology, Circa 
1960 


In the 1960’s, phones became equipped with a new 
technology known as dual-tone multifrequency 
signaling aka DTMF. 


DTMF was an audio-based signaling language 
developed by Bell Systems and patented under the 
more commonly known trademark “Touch Tones”. 


DTMF was intrinsicly tied to the phone dial layout we 
know today that consists of three columns and four 
rows of numbers. Each of the keys on a DIMF phone 
emitted two very specific audio frequencies, versus a 
single frequency like the original tone dialing systems. 


The development of DIMF was due largely to the fact 
that phreakers had been taking advantage of tone 
dialing systems due to how easy those systems where 
to reverse engineer. Bell Systems believed that 
because DTMF systems used two very different tones 
at the same time, it would be much more difficult for a 
malicious actor to take advantage of the system. 


DMTF tones could not be easily replicated by a human 
voice or a whistle, which meant the technology was 
significantly more secure than it’s predesessor. DIMF 
was a prime example of a successful security 
development that was introduced in order to combat 
phreakers, the hackers of that era. 


The mechanics behind how DTMF tones were 
generated are pretty simple. Behind each key is a 
switch which signals to an internal speaker to emit two 
frequencies - one frequency based on the row of the 
key and one frequency based on the column. Hence 
the use of the term “dual-tone”. 
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DTMF was adopted as a standard by the International 
Telecommunication Union and would later go on to be 
used in cable TV (to specify commercial break times) in 
addition to phones. 


DTMF is an important technological development 
because it shows that systems can be engineered to be 
more difficult to abuse if proper planning is taken. Do 
note these DTMF tones would eventually be duplicated 
as well - but the effort required would be significantly 
greater, 


Eventually switching centers would move to digital 
(versus analog) inputs which would eliminate nearly all 
phreaking. 


The Origins of Computer Hacking, 
Circa 1980 


In 1976 Apple released the Apple 1 personal computer. 
This computer was not configured out of the box and 
required the buyer to provide a number of components 
and connect them to the motherboard. Only a few 
hundred of these devices where built and sold. 


In 1982, a Commodore International would release 
their own competitor device. This device was the 
Commodore 64 - a personal computer that was 
completely configured right out of the box. It came 


with it’s own keyboard, could supported audio and 
even could even be used with multicolor displays. 


The Commodore 64 would go on to sell nearly 500,000 
units per month until the early 1990’s. From this point 
forward the sales trend for personal computers would 
continually increases year over year for several 
decades to come. 


Computers would soon become a common tool in 
households as well as businesses, and take over 
common repetetive tasks such as managing finances, 
human resources, accounting and sales. 


In 1983 Fred Cohen, an American computer scientist 
would go on to demonstrate the very first computer 
virus. The virus he wrote was capable of making copies 
of itself, and being easily spread from one personal 
computer to another via floppy disk. He was able to 
store the virus inside of a legitimate program, masking 
it from anyone who did not have source code access. 


Fred Cohen would later become known as a pioneer in 
software security, and go on to demonstrate that 
detecting viruses from valid software with algorithms 
was almost impossible. 


A few years later in 1988 another American computer 
scientiest named Robert Morris would be the first 


person to ever deploy a virus that would infect 
computers outside of a research lab. The virus would 
go on to be known as the “Morris Worm”, with “worm” 
being a new phrase used to describe a self-replicating 
computer virus. 


The Morris Worm would spread to about 15,000 
network attached computers within the first day of it’s 
release. 


For the first time in history, the U.S. Government would 
step in to consider official regulations against hacking. 
The U.S. Government Accountability Office estimated 
the damage caused by this virus at as much as 
$10,000,000. 


Robert would recieve three years of probation, 400 
hours of community service and a fine of $10,050. This 
would make him the first convicted hacker in the USA. 


These days most hackers do not build viruses that 
infect operating systems, but instead target web 
browsers. Modern browsers provide extremely robust 
sandboxing which makes it difficult for a website to 
run executable code outside of the the browser (aka, 
against the host operating system) without explicit 
user permission. 


Although hackers today are primarly targeting users 
and data that can be accessed via web browser there 
are many similarities to those that targetted the OS. 
Scalability (jumping from one user to another) and 
camoflauging (hiding malicious code inside of a 
legitimate program) are both techniques employed by 
attacks against web browsers. 


Today attacks scale often by distribution through 
email, social media or instant messengers. Some 
hackers even build up legitimate networks of real 
websites in order to promote a single malicious 
website. 


Often times malicious code is hidden behind a 
legitimate looking interface. Phishing (credential 
stealing) attacks occur on websites that look and feel 
identical to social media or banking sites. Often times 
browser plugins are caught stealing data, and 
sometimes hackers even find out ways to run their own 
code on websites they do not own. 


The Rise of the World Wide Web, 
Circa 2000 


The World Wide Web (WWW) would spring up in the 
1990’s, but it’s popularity would begin to explode at 
the end of the 1990’s and the early 2000’s. 


Around the early 2000’s, the web would begin to adapt 
and change. 


In the 1990’s, the web was almost exclusively used as a 
way of sharing documents written in HTML. Websites 
did not pay attention to user experience, and very few 
allowed the user to send any inputs back to the server 
in order to modify the flow of the website. 


The early 2000’s would mark a new era for the 
internet because websites would begin to store user 
submitted data and modify the functionality of the site 
based on the user’s input. This would be a key 
development later known as “Web 2.0”. 


Web 2.0 websites allowed users to collaborate with 
eachother via submitting their inputs over hyper text 
transport protocol (HTTP) to a webserver which would 
than store the inputs and share them with fellow users 
UpoMmrequesr. 


This new ideology in building websites would give birth 
to social media as we know it today. Web 2.0 enabled 
blogs, wikis, media sharing sites and more. 


This radical change in web ideology would cause the 
web to change from a document sharing platform to an 
application distribution platform. 


This huge shift in architecture design direction for 
websites would also change the way that hackers 
target web applications. By now, serious efforts had 
been taken to secure servers and networks - the two 
leading attack vectors for hackers of the last decade. 


With the rise of application-like websites, the user 
would become an perfect target for hackers. 


It was a perfect setup. Users would soon have access 
to mission-critical functionality over the web. Military 
communications, bank transfers, and more would all 
eventually be done through web applications (a 
website that operates like a desktop application). 


Unfortunately, there where very few security controls 
in place at the time to protect users against attacks 
that targetted them. Furthermore, education 
regarding hacking or the mechanisms that the internet 
ran on where very scarce. Few early internet users in 
the 2000’s could even begin to grasp the underlying 
technology that acted as an enabler for them. 


In early 2000’s, the first largely publicized denial of 
service (DDoS) attacks would shut down Yahoo, 
Amazon, Ebay and other popular sites. 


In 2002, Microsoft’s ActiveX plugin for browsers would 
end up with a vulnerability that would allow remote file 


uploads and downloads to be invoked by a website 
with malicious intentions. 


By the mid 2000’s hackers would regularly utilize 
“phishing” websites to steal credentials. No controls 
where in place at the time to protect users against 
these websites. 


Cross Site Scripting vulnerabilities that allowed a 
hacker’s code to run in a user’s browser session inside 
of a legitimate website would run rampant throughout 
the web during this time, as browser vendors had not 
yet been able to build defenses for such attacks. 


Many of the hacking attempts of the 2000’s came asa 
result of the technology driving the web being 
designed for a single user (the website owner). These 
technologies would topple when used to build a system 
that allowed the sharing of data between many users. 


Hackers in the Modern Era, Circa 
2015+ 


The whole point in discussing hacking in previous eras 
was in order to build a foundation from which we can 
begin our journey in this book. 


From analyzing the development and cryptoanalysis of 
Enigma Machines in the 1930’s we gained insight into 


the importance of security, and the lengths that others 
will go to in order to break said security. 


In the 1940’s we saw an early use case for security 
automation. This particular case was driven by the 
ongoing battle between attackers and defenders. In 
this case, the Enigma Machine technology had 
improved so much it could no longer be reliably 
broken by manual cryptoanalysis techniques. As a 
result, Alan Turing turned to automation in order beat 
the aforementioned security improvements. 


The 1950’s and 1960’s showed us that hackers and 
tinkerers have a lot in common. We also learned that 
technology designed without considering users with 
malicious intent will lead to said technology eventually 
being broken. We must always consider the worst-case 
scenario when designing technology to be deployed at 
scale and across a wide userbase. 


In the 1980’s the personal computer started to 
become popular. Around this time period we would 
begin to see the hackers we recognize today emerge. 
These hackers would take advantage of the powers 
that software enables, camoflauging viruses inside of 
legitimate applications and using networks to spread 
their viruses rapidly. 


Finally, the introduction and rapid adoption of the 
World Wide Web would lead to the development of 
Web 2.0. Web 2.0 would change the way we think 
about the internet. Instead of the internet being a 
medium for sharing documents, it would become a 
medium for sharing applications. As a result of this, 
new types of exploits would emerge that take 
advantage of the user rather than the network or 
server. This is a fundamental change that is still true 
today, as most of today’s hackers have moved to 
targeting web applications via browsers instead of 
desktop software and operating systems. 


Let’s jump ahead to 2019, the year when I started 
writing this book. As of the time of writing, there are 
literally thousands of websites on the web that are 
backed by million and billion dollar companies. In fact, 
many companies make all of their revenue off of their 
websites. Some examples you are probably familiar 
with are: Google, Facebook, Yahoo, Reddit, Twitter, etc. 


Some traditional desktop software companies are now 
trying to move their product lineup to the web, to what 
is known today as “the cloud” but is simply a complex 
network of servers. Examples of this include Adobe 
with “Creative Cloud” - a subscription offering that 
provides Photoshop and other Adobe tools via the web, 
and Microsoft Office - which of course provides Word 
and Excel, but now as a web application. 


Because of how much money is parked in web 
applications, the stakes are the highest they have ever 
been. This means applications today on the web are 
ripe for exploitation, and the rewards for exploiting 
them are sky high. 


This is truely one of the best eras to be in for both 
hackers and engineers who emphasize security. Work 
for both is in high demand, and on both sides of the 
law. 


Browsers have become significantly more advanced 
than they where 10 years ago. Alongside this 
advancement has come a host of new security features. 
The networking protocols we use to access the 
internet have advanced as well. 


Today’s browsers offer very robust isolation between 
websites with different origins, following a security 
specification known as Same Origin Policy (SOP). This 
basically means website A cannot be accessed by 
website B even if they are both open at once or one is 
embedded as an iframe inside of the other. 


Browsers also accept a new security configuration 
known as Content Security Policy (CSP). CSP allows 
the developer of a website to specify various levels of 
security, for example if scripts should be able to 
execute inline (in the HTML). This allows web 


developers to further protect their applications against 
common threats. 


HTTP - the main protocol for sending web traffic has 
also improved from a security perspective. HTTP has 
adopted protocols like SSL and TLS which enforce 
strict encryption for any data traveling over the 
network. This makes man in the middle attacks very 
difficult to pull off successfully. 


As a result of these advancements in browser security, 
many of the most successful hackers today are actually 
targetting the logic written by developers that runs in 
their web applications. 


Instead of targeting the browser itself, it is much 
easier to successfully breach a website by taking 
advantage of bugs in the application’s code. 
Fortunately for hackers, web applications today are 
many times larger and more complex than web 
applications of the past. 


Often today, a well known web application can have 
hundreds of open source dependencies, integrations 
with other websites, multiple databases of various 
types and be served from more than one web server in 
more than one location. 


These are the types of web applications you will find 
the most success in exploiting, and the types of web 
applications we will be focusing on throughout this 
book. 


To summarize, today’s web applications are much 
larger and more complex than their predecessors. As a 
hacker, you can now focus on breaking into web 
applications by exploiting logic bugs in the application 
code. Often these bugs result as a side effect of 
advanced user-interaction featured within the web 
application. 


The hackers of the last decade focused much of their 
time breaking into servers, networks and browsers. 
The modern hacker spends most of their time breaking 
into web applications by expoiting vulnerabilities 
present in code. 
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